Skip to content

PhoneWindowManager: honor disabled screen-on reclaim setting - #1336

Open
CeRRiLLo89 wants to merge 1011 commits into
crdroidandroid:16.0from
CeRRiLLo89:raphael-screen-on-reclaim-fix
Open

PhoneWindowManager: honor disabled screen-on reclaim setting#1336
CeRRiLLo89 wants to merge 1011 commits into
crdroidandroid:16.0from
CeRRiLLo89:raphael-screen-on-reclaim-fix

Conversation

@CeRRiLLo89

@CeRRiLLo89 CeRRiLLo89 commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Summary

Re-read SCREEN_ON_MEMORY_RECLAIM immediately before executing the delayed
screen-on memory reclaim.

Problem

PhoneWindowManager schedules mMemoryOpt from the cached
mScreenOnReclaim value and executes the callback 1250 ms later.

The callback previously called releaseMemoryAtScreenOn() without checking
the current setting again.

On raphael with crDroid Android 16, screen-on reclaim was reproduced while:

  • the active user was 0;
  • screen_on_memory_reclaim was 0;
  • the exact-build mitigation module was disabled;
  • the original services.jar was active.

One controlled screen-on cycle produced the reclaim log 1251 ms after wake
and killed 25 cached processes, including the Android Auto car process.

The exact reason for the stale cached state has not been proven. It may involve
setting-observer timing or cross-thread visibility.

Change

  • Centralize the current setting lookup.
  • Mark the cached flag volatile because it is updated and read from different
    execution contexts.
  • Re-read the setting before the delayed callback releases memory.
  • Preserve the existing reclaim behavior when the setting is enabled.
  • Expose the delayed callback for unit testing with @VisibleForTesting.
  • Isolate the two reclaim tests from the complete PhoneWindowManager
    initialization, because the callback only requires the settings context and
    the ActivityManager service.

This does not modify:

  • LMKD
  • ZRAM
  • Cached App Freezer
  • the reclaim interval
  • the reclaim parameters
  • system_server garbage collection

Tests

Added unit coverage verifying that:

  • a disabled setting at callback execution prevents releaseMemory() from
    being called;
  • an enabled setting at callback execution preserves the existing reclaim
    call.

The tests initialize only the dependencies required by the delayed reclaim
callback instead of initializing the complete PhoneWindowManager policy.
This avoids activating unrelated camera, role-management, device-key, and
Lineage settings subsystems during the unit test.

The ActivityManager call is mocked, so the tests do not perform a real process
reclaim.

Local validation was completed with the lineage_raphael userdebug target and
a physical Xiaomi Mi 9T Pro / Redmi K20 Pro (raphael) running Android 16 /
crDroid 12.11.

Executed tests:

WmTests:com.android.server.policy.PhoneWindowManagerTests#screenOnMemoryReclaimDisabledAtExecution_doesNotReleaseMemory

WmTests:com.android.server.policy.PhoneWindowManagerTests#screenOnMemoryReclaimEnabledAtExecution_releasesMemory

Result:

  • WmTests compilation: passed
  • Instrumentation installation: passed
  • Tests selected: 2
  • Passed: 2
  • Failed: 0
  • Disabled at execution: passed
  • Enabled at execution: passed

The local crDroid WmTests baseline required two unrelated compatibility
adjustments in separate test files. Those adjustments were used only in the
local validation harness and are not included in this pull request.

Device context

Device: Xiaomi Mi 9T Pro / Redmi K20 Pro (raphael)

Build: crDroid Android 16 v12.11-20260623

Validated pull request head:

60a3492aa2756fdad29b5a502b6cfa8acfff9d73

The exact-build KernelSU mitigation remains enabled until a ROM build
containing this source change is available for controlled validation.

Validation status

  • Controlled device reproduction: completed.
  • Source review: completed.
  • WmTests source compilation: completed.
  • Targeted unit test execution: completed, 2 passed / 0 failed.
  • Pull request test isolation update: completed.
  • Device validation with a ROM build containing this change: pending.

neobuddy89 and others added 30 commits June 28, 2026 18:17
* Treat classic tiles as icon only so that we apply color and bounceable
  animation correctly.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Ref: https://github.com/BootleggersROM/packages_overlays_Shishufied/tree/queso/QSTiles

* Regenerate path and adapt for our implementation.
* Add separate outline tile color to make it distinct.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
[neobuddy89: Do not change style, only weight]

Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Keep the discrete steps but hide the visual tick marks for a more
cleaner look.

Change-Id: I3585f62d0126afb00223104192a4cedfcdf13cbe
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Treat empty attribution tags the same way as null in
isAttributionInPackage().

This avoids repeated AppOps error logs from pre-S apps that pass an empty
string attribution tag even though they could not declare <attribution>
entries in their manifest.

Change-Id: Ieecdba9130328ab9de3c1e16d9b2100b288ce492
Signed-off-by: Quince <quinceroms@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Only log and start IME hide tracking when the IME is actually requested
visible or when a user-controlled IME animation is active.

This avoids repeated hide(ime()) log spam and unnecessary ImeTracker token
allocation when clients keep asking to hide an already hidden IME.

Change-Id: Iff27ec1b4c7c8236346c18996b776f34612c8975
Signed-off-by: Quince <quinceroms@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Remove the delayed dismiss message when LogAccessDialogActivity is
destroyed and guard the final dialog dismiss in onClick().

This prevents stale timeout callbacks from interacting with a detached
DecorView after configuration changes.

Change-Id: Ib8abe68cb4c7aa95dd90b9c67d1b6ac7cd3706b3
Signed-off-by: Quince <quinceroms@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I64d455835389acb2e591ff0b623797e1e122f06d
Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
During USB headset disconnection, AudioDeviceBroker synchronously
restores mBluetoothA2dpEnabled=true, but mGlobalBluetoothA2dpOn in
MediaRouterService is only updated later via the asynchronous
dispatchAudioRoutesChanged callback. A playback state change in this
transient window causes restoreBluetoothA2dp() to read the stale
mGlobalBluetoothA2dpOn=false and call setBluetoothA2dpOn(false),
overriding the already-restored A2DP state and suppressing Bluetooth
audio output.

Fix by cross-checking with AudioService.isBluetoothA2dpOn() before
setting A2DP off. When the two states are inconsistent (local says
off but AudioService says on), skip the stale request.

Bug: 498786084
Test: 1. Connect Bluetooth headphones and play music.
2. Plug in USB headphones.
3. Unplug USB headphones.
Flag: EXEMPT bug fix

Change-Id: I98a64166f0f130347cb90cebf362c6d1a9935024
Signed-off-by: chenxin20 <chenxin20@xiaomi.com>
…in scenarios involving dual instances of the app.

Perform a backup for each user.

Test: atest
Bug:498471068

Change-Id: Ib3cd2fbd58a8039a9c0a598e9d6346ff3b00e01c
Signed-off-by: luanzhuang <luanzhuang@xiaomi.corp-partner.google.com>
… for lock screen unlocking

Bug: 499150034
Test:
1. Set PIN unlock method
2. Lock it and press the unlock button
3. Intentionally enter the wrong password and wait for the countdown.
4. During the countdown, repeatedly open and close the unlock disc
5. Check if the countdown is correct

Change-Id: I7c15a95a7871a04ec0a71f5405be2d014aadfe45
Change-Id: I2aaa9e526b6f1a35d45e96b6d23e3db972d82733
Signed-off-by: Joey Huab <joey@evolution-x.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
A leak can occur for any app that uses StrictMode#enableDefaults or sets
StrictMode.VmPolicy.Builder's detectBlockedBackgroundActivityLaunch or detectAll. If any of those
are called or set, every call to StrictMode#setVmPolicy (this is used in core framework code like
LoadedApk) will trigger StrictMode#registerBackgroundActivityLaunchCallback. This registers a brand
new callback every time.

In system_server, these new callbacks are just stored in an ArrayMap in
BackgroundActivityStartController's addStrictModeCallback which uses the IBinder as the map key.
Since every new BackgroundActivityLaunchCallback is a distinct IBinder, containsKey(callback) never
returns true for a new callback instance from StrictMode.

For userdebug/eng builds, this leak can also occur in any bundled system app due to the logic in
StrictMode#initVmDefaults. In particular, SystemUI can crash because of this leak. When such a crash
occurs, the following is printed out (UID 10126 is SystemUI):

V Binder  : BinderProxy descriptor histogram (top 10):
V Binder  :  # 1: android.app.IBackgroundActivityLaunchCallback x5698
V Binder  :  # 2: android.content.IIntentReceiver x471
V Binder  :  # 3: android.content.IContentProvider x304
V Binder  :  # 4: android.database.IContentObserver x237
V Binder  :  # 5: android.app.IApplicationThread x140
V Binder  :  # 6: com.android.internal.os.IResultReceiver x135
V Binder  :  # 7: android.app.IUnsafeIntentStrictModeCallback x92
V Binder  :  # 8:  x86
V Binder  :  # 9: <cleared weak-ref> x83
V Binder  :  # 10: <proxy to dead node> x54
D Binder  : Per Uid Binder Proxy Counts:
...
D Binder  : UID : 10126  count = 6006
...
E BpBinder: Too many binder proxy objects sent to uid 1000 from uid 10126 (... proxies held)
E ActivityManager: Uid 10126 sent too many Binders to uid 1000
...
I ActivityManager: Killing 2145:com.android.systemui/u0a126 (adj -800): Too many Binders sent to SYSTEM
I am_kill : [User=0,PID=2145,Process Name=com.android.systemui,OomAdj=-800,Reason=Too many Binders sent to SYSTEM,Rss=477156B]

StrictMode#initVmDefaults calls builder.detectAll() for all bundled system apps on userdebug and eng
builds. detectAll() includes DETECT_VM_BACKGROUND_ACTIVITY_LAUNCH_ABORTED. SystemUI is a bundled
system app, so it gets this flag at startup. With this flag, every call to StrictMode#setVmPolicy
will trigger StrictMode#registerBackgroundActivityLaunchCallback.

A hot path is in LoadedApk which SystemUI calls very often when managing notification UI. In
LoadedApk#canAccessDataDir, the following pattern is used which should demonstrate how this leak
can happen:

StrictMode.VmPolicy old = StrictMode.allowVmViolations();
try {
    // StrictMode violation code
} finally {
    StrictMode.setVmPolicy(old); // re-registers a new BAL callback every time
}

It's not unexpected for other apps to be following this pattern as well.

The following is a stacktrace of how SystemUI adds new BAL callbacks. This runs on every
notification that gets posted:

```
W StrictMode: java.lang.Throwable
W StrictMode:     at android.os.StrictMode.registerBackgroundActivityLaunchCallback(StrictMode.java:2230)
W StrictMode:     at android.os.StrictMode.setVmPolicy(StrictMode.java:2222)
W StrictMode:     at android.app.LoadedApk.setVmPolicy(LoadedApk.java:875)
W StrictMode:     at android.app.LoadedApk.canAccessDataDir(LoadedApk.java:1170)
W StrictMode:     at android.app.LoadedApk.createOrUpdateClassLoaderLocked(LoadedApk.java:962)
W StrictMode:     at android.app.LoadedApk.getClassLoader(LoadedApk.java:1183)
W StrictMode:     at android.app.ActivityThread.getTopLevelResources(ActivityThread.java:3169)
W StrictMode:     at android.app.ApplicationPackageManager.getResourcesForApplication(ApplicationPackageManager.java:2199)
W StrictMode:     at android.app.ApplicationPackageManager.getResourcesForApplication(ApplicationPackageManager.java:2182)
W StrictMode:     at android.app.ApplicationPackageManager.getResourcesForApplication(ApplicationPackageManager.java:2218)
W StrictMode:     at android.graphics.drawable.Icon.loadDrawableAsUser(Icon.java:616)
W StrictMode:     at com.android.systemui.statusbar.StatusBarIconView.getIcon(StatusBarIconView.java)
W StrictMode:     at com.android.systemui.statusbar.StatusBarIconView.updateDrawable(StatusBarIconView.java)
W StrictMode:     at com.android.systemui.statusbar.StatusBarIconView.set(StatusBarIconView.java)
W StrictMode:     at com.android.systemui.statusbar.notification.icon.IconManager.setIcon(IconManager.java)
W StrictMode:     at com.android.systemui.statusbar.notification.icon.IconManager.createIcons(IconManager.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.inflation.NotificationRowBinderImpl.inflateViews(NotificationRowBinderImpl.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.NotifInflaterImpl.inflateViewsImpl(NotifInflaterImpl.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator.inflateEntry(PreparationCoordinator.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator.inflateRequiredNotifViews(PreparationCoordinator.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator.inflateRequiredGroupViews(PreparationCoordinator.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator$$ExternalSyntheticLambda2.onBeforeFinalizeFilter(PreparationCoordinator.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.ShadeListBuilder$$ExternalSyntheticLambda12.accept(ShadeListBuilder.java)
W StrictMode:     at com.android.systemui.util.NamedListenerSet.forEachTraced(NamedListenerSet.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.ShadeListBuilder$$ExternalSyntheticLambda7.run(ShadeListBuilder.java)
W StrictMode:     at com.android.systemui.statusbar.notification.collection.NotifPipelineChoreographerImpl$frameCallback$1.doFrame(NotifPipelineChoreographerImpl.kt)
W StrictMode:     at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1628)
W StrictMode:     at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1639)
W StrictMode:     at android.view.Choreographer.doCallbacks(Choreographer.java:1235)
W StrictMode:     at android.view.Choreographer.doFrame(Choreographer.java:1160)
W StrictMode:     at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1613)
```

There's also another path from
com.android.systemui.statusbar.notification.collection.coordinator.MediaCoordinator.shouldFilterOut
not shown here.

The SystemUI crash only occurs on userdebug/eng, but any app using the BAL StrictMode methods or the
StrictMode#enableDefaults will have this leak as well.

Note that StrictMode's BackgroundActivityLaunchCallback only calls static methods, so there's really
no point in making new instances for every call. system_server doesn't do anything with newly added
callbacks other than add it to an ArrayMap and link a death recipient. This also follows the
approach of StrictMode's existing usage of sUnsafeIntentCallback.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
fix for mtk and low-end devices perf regression caused by fixed dp translate and fade animation

Change-Id: Ibaf8a426b6e1d819dde9f131c8ef50b0268d24e9
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I0bc91f3c97af7995fc3174f72dedd6febb291ec6
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
preloading the animations during application bind, makes the activity loading way more faster, removing the latency during activity launch click

Change-Id: I8ae7e6c950d710593e695e94ae152d6815637d67
Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Change-Id: Ieec1869bac37104cd8733278865cf44e773b8971
Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I8c436985a1c7c2a96453f5163022ff279e82af90
Signed-off-by: Saikrishna1504 <saikrishna26918@gmail.com>
…margin

On devices with a low-positioned UDFPS icon, the lockscreen chip can
overlap and render behind it in collapsed mode.

Align the chip with the keyguard indication margin and use the
`keyguard_indication_margin_bottom` overlay to adjust placement per
device as needed.

Change-Id: I4f253bc37ba3f565f4c480ce30a4f3beabfc7d9e
fix notification animation oscillation during expansion - use aosp transition api
fix resource usage when showing media chip - remove waveform animation and use 1 iteration marquee
low udfps position algorithm
chip content changes transform animaton

Change-Id: I9087d504bf126c7d8b5d35486f9d39e6b0564026
AxionAOSP/issue_tracker#110

Change-Id: Ib95eb4807a374d362734c940c3f82a118b3a301b
Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I3777f3899ede8b2bc94e64aeaeac7fa4dd262ab1
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I29bca3b6435ac95bf4dc76ac95bf4dc76ac95bf5
Signed-off-by: Saikrishna1504 <saikrishna26918@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I29bca3b6435ac95bf4dc76ac95bf4dc76ac95bf6
Signed-off-by: Saikrishna1504 <saikrishna26918@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: Iec04c3b59cfb0200ddd33e7ee92c212a1a6f44ae
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
removing unncecessary events | rewiring to aosp status bar chip

Change-Id: Ib1c2bbcd09c871ff14a2c18f485bee22874679a1
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
[neobuddy89: This is trimmed version for dynamic bar usage.]

Co-authored-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
elluzion and others added 22 commits July 11, 2026 10:54
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Dmitrii <bankersenator@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
The mProfilerSnapshotTimer, defined internally by SystemServer in 2014, is no longer in use and should be removed.

Signed-off-by:
Shuangxi Xiang <xiangshuangxi@xiaomi.corp-partner.google.com>

Change-Id: I2ae871561b4a5440d465a9568af7f761026dc0c6
If the current notification list contains only one group notification, and that group notification includes both OnGoing notifications and normal notifications,
the Clear All button will display normally.
However, when Clear All is executed, there is no animation; normal notifications are simply deleted, and the panel does not collapse. This is because viewsToAnimateAway is empty at this point, but rowsToDismissInBackground is not empty.There is no animation

bug:531917470

Change-Id: I44ee42ef3e77f01328e365b4c55e7aca93267089
* New translations cr_strings.xml (Romanian)

[ci skip]

* New translations cr_strings.xml (French)

[ci skip]

* New translations cr_strings.xml (Spanish)

[ci skip]

* New translations cr_strings.xml (Arabic)

[ci skip]

* New translations cr_strings.xml (Belarusian)

[ci skip]

* New translations cr_strings.xml (Bulgarian)

[ci skip]

* New translations cr_strings.xml (Catalan)

[ci skip]

* New translations cr_strings.xml (Czech)

[ci skip]

* New translations cr_strings.xml (German)

[ci skip]

* New translations cr_strings.xml (Greek)

[ci skip]

* New translations cr_strings.xml (Finnish)

[ci skip]

* New translations cr_strings.xml (Hebrew)

[ci skip]

* New translations cr_strings.xml (Hungarian)

[ci skip]

* New translations cr_strings.xml (Italian)

[ci skip]

* New translations cr_strings.xml (Japanese)

[ci skip]

* New translations cr_strings.xml (Korean)

[ci skip]

* New translations cr_strings.xml (Kurdish)

[ci skip]

* New translations cr_strings.xml (Dutch)

[ci skip]

* New translations cr_strings.xml (Polish)

[ci skip]

* New translations cr_strings.xml (Portuguese)

[ci skip]

* New translations cr_strings.xml (Russian)

[ci skip]

* New translations cr_strings.xml (Slovak)

[ci skip]

* New translations cr_strings.xml (Turkish)

[ci skip]

* New translations cr_strings.xml (Ukrainian)

[ci skip]

* New translations cr_strings.xml (Chinese Simplified)

[ci skip]

* New translations cr_strings.xml (Chinese Traditional)

[ci skip]

* New translations cr_strings.xml (Vietnamese)

[ci skip]

* New translations cr_strings.xml (Portuguese, Brazilian)

[ci skip]

* New translations cr_strings.xml (Indonesian)

[ci skip]

* New translations cr_strings.xml (Persian)

[ci skip]

* New translations cr_strings.xml (Estonian)

[ci skip]

* New translations cr_strings.xml (Azerbaijani)

[ci skip]

* New translations cr_strings.xml (Santali)

[ci skip]
Flag: com.android.systemui.flashlight_strength
Bug: 446110051
Test: manual. open flashlight dilaog, verify separator has enough contrast from the background.

Change-Id: Iaaaecfdd0941e75e519358546c9b1e74e00ac848
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
When removing a media card, pagerState.currentPage could be updated out of
sync with the viewModel cards, causing a crash.
This change adds viewModel.cards.size as a key so that we get both relevant
updates, and only call onCardSelected when valid.

Fixes: 452266758
Test: QSMediaControllerUmoInQqsAndQs
Test: manual - add/remove multiple media players
Flag: com.android.systemui.scene_container
Flag: com.android.systemui.media_controls_in_compose
Change-Id: I555b8a80651e79296cb4809c52306d741e6bd06d
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Flag: com.android.systemui.scene_container
Flag: com.android.systemui.media_controls_in_compose
Fix: 468267280
Test: Checked UI - taps on playPause button on UMO.
Change-Id: I013a7e51e0b4f0f741e8c6d80c39345cdf227df7
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I99b63bb159bf501049d9b16b755141c8d06a53f7
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I253aeb9c6f1344cfd1e637aa96b3e8f9d68ecb30
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I6c927575d1ccd0a5af1f1d43fa6ca6e949380583
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I1c2201b2eac267c1af7b65ad31327c517c8803c8
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I684dc77bd89fcab8fb51b342a3dc76c3b6afe687
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I14a14ab89afbecaca4b2af59403ed3b5b1eda37c
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
the backdrop was heavy and messy, mtk hates complex fade animations, programatically load app start animation to reduce pressure during splash screen animation, simpleperf shows parsing the animation from xml consumes high cpu usage due to resource lookup.

Change-Id: Icc38c2d3db1a05ceedf41433d13cc75a8de7732f
Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
* New translations cr_strings.xml (Vietnamese)

[ci skip]

* New translations cr_strings.xml (Japanese)

[ci skip]

* New translations cr_strings.xml (Japanese)

[ci skip]

* New translations cr_strings.xml (Japanese)

[ci skip]

* New translations cr_strings.xml (French)

[ci skip]

* New translations cr_strings.xml (German)

[ci skip]

* New translations cr_strings.xml (Persian)

[ci skip]

* New translations cr_strings.xml (Vietnamese)

[ci skip]

* New translations cr_strings.xml (Chinese Traditional)

[ci skip]

* New translations cr_strings.xml (Persian)

[ci skip]

* New translations cr_strings.xml (Persian)

[ci skip]

* New translations cr_strings.xml (Spanish)

[ci skip]

* New translations cr_strings.xml (Korean)

[ci skip]
Screen-on reclaim is scheduled from a cached setting and executes after a 1250 ms delay.

Re-read SCREEN_ON_MEMORY_RECLAIM before running the delayed reclaim so the disabled state is honored even if the cached value is stale or the setting changes after scheduling.

Mark the cached flag volatile because it is updated by the settings observer and read from the power notifier path.
Remove whitespace from the blank line after mMemoryOpt.
Verify that the delayed screen-on reclaim callback rechecks the current
SCREEN_ON_MEMORY_RECLAIM setting before releasing memory.

Cover both the disabled and enabled paths while stubbing the ActivityManager
call to avoid running a real reclaim during the test.
@CeRRiLLo89

CeRRiLLo89 commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

Validation update for the current pull request head:

60a3492aa2756fdad29b5a502b6cfa8acfff9d73

The controlled device reproduction was performed on a Xiaomi Mi 9T Pro /
Redmi K20 Pro (raphael) running crDroid Android 16
v12.11-20260623.

Reproduction conditions:

  • active user: 0;
  • screen_on_memory_reclaim=0;
  • exact-build mitigation module disabled;
  • original services.jar active.

Observed result:

  • screen wake: 20:37:33.443;
  • screen-on reclaim: 20:37:34.694;
  • wake-to-reclaim delay: 1.251 seconds;
  • 25 cached processes killed;
  • kill reason: screen-on memory reclaim.

Source validation was completed using the real
lineage_raphael userdebug target.

Executed tests:

WmTests:com.android.server.policy.PhoneWindowManagerTests#screenOnMemoryReclaimDisabledAtExecution_doesNotReleaseMemory

WmTests:com.android.server.policy.PhoneWindowManagerTests#screenOnMemoryReclaimEnabledAtExecution_releasesMemory

Result:

  • WmTests compilation: passed.
  • Instrumentation installation: passed.
  • Tests selected: 2.
  • Passed: 2.
  • Failed: 0.
  • Disabled setting at callback execution: passed.
  • Enabled setting at callback execution: passed.

The tests use a mocked ActivityManager service, so they validate the
framework-side callback behavior without performing a real process reclaim.

The pull request was also integrated successfully into a complete
lineage_raphael userdebug build.

The local ROM package passed compilation, packaging, VINTF and ZIP integrity
checks, but was not installed because it is signed with the AOSP test key
while the installed official crDroid ROM trusts the crDroid release key.

Runtime validation with an official ROM build containing this change remains
pending.

The exact-build mitigation module remains enabled on
v12.11-20260623.

This pull request is ready for maintainer review.

Runtime validation with an official crDroid build remains pending because the
locally built package is signed with the AOSP test key and cannot be installed
as an update over the installed official release-key build.

@CeRRiLLo89
CeRRiLLo89 marked this pull request as ready for review August 3, 2026 09:05
@neobuddy89

Copy link
Copy Markdown
Member

Squash commits.

@neobuddy89

Copy link
Copy Markdown
Member

ideally... dont see current code to be wrong.
Do you mean after toggle is off... it still keeps running after every screen on or just one screen on?

@CeRRiLLo89

Copy link
Copy Markdown
Contributor Author

Only one controlled screen-on cycle was reproduced.

In that reproduction, "screen_on_memory_reclaim" was already "0" before the wake and remained "0" afterwards, but the delayed screen-on reclaim still executed 1.251 seconds later and killed 25 cached processes.

So I can confirm the issue for that controlled reproduction, but I cannot currently claim that it continued after every subsequent screen-on.

I'll also squash the commits in the next couple of days. I'm currently away from my PC

@neobuddy89
neobuddy89 force-pushed the 16.0 branch 3 times, most recently from bf065ba to 708e793 Compare August 8, 2026 16:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.